An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hi all, I submitted my first app for review on Friday evening and it's currently in "Waiting for Review". As a first-time developer I'm just curious about the process: What review times are you all seeing lately for a brand-new (first version) app? Does the weekend tend to slow things down, or is review running 7 days a week? For an app that requires sign-in, is it common for review to take a little longer since the reviewer has to log in and test? Not in a rush, just curious what to expect. Thanks!

Hi everyone,  I'm a relatively new developer and I just received my first App Store rejection. I'm posting here because I'm genuinely stuck and hoping the community can help me figure out where to even begin.  The Problem:  My app was rejected under Guideline 5.6 - Developer Code of Conduct - Review Suspended. The full message is the standard one: the app doesn't meet the "required quality standard," it's "not eligible for resubmission," and I should "ensure every screen, interaction, and piece of content has been thoughtfully designed" before submitting a new app.  Here's why I'm confused:  The rejection came with ZERO attachments. No screenshots. No screen recordings. No crash logs. No specific mention of a buggy feature, a broken button, or an unfinished screen. It's just a blanket statement about "quality" and "polish."  in my case, there's absolutely nothing to go on.  What I've checked so far:  I've tested the app on multiple physical devices (iPhone 12, 14, 15) – no crashes. I've reviewed every screen for placeholder text, "Lorem Ipsum," or dummy images – none found. I've checked the In-App Purchase / subscription screen for proper legal disclaimers and auto-renewal text – all present. I've made sure there are no debug logs or test toggles left in the production build. Everything looks fine to me, which is why I'm so lost. Without specific feedback, I don't know if the issue is:  A UI inconsistency I'm blind to? A subtle crash that only happens on a device I don't own? An issue with the paywall flow that I've misunderstood? Something about the metadata, screenshots, or app description? My questions for the community:  Has anyone else received a Guideline 5.6 rejection with no attachments? Is this common, or does it suggest the reviewer flagged the app as "low-quality" purely based on first impressions (like the design feels outdated or the concept is too simple)? Since the message says replies and resubmissions of this binary won't be reviewed, and I can't get clarification from the reviewer, what's the safest way to proceed? Should I:  Create a completely new App ID and submit as a new app? Or can I submit a new version under the same App ID? (I've heard mixed answers on this.) More importantly – how do I figure out what to fix? Without a starting point, I'm worried I'll fix the wrong things and get rejected again, which I know can lead to account termination after repeated violations. Are there any "hidden" quality checks that reviewers apply that aren't obvious to developers? For example, does Apple penalize apps that:  Have a generic icon or unpolished splash screen? Take too long to load on first launch? Have unclear navigation or confusing user flow? Lack a proper onboarding/tutorial for first-time users?   Thanks in advance for any help you can offer. I really want to get this right and not waste my one or two remaining chances. my app id : 6764726742

Hi, I'm looking for some guidance regarding my first App Store submission. My app has been stuck In "Waiting for Review" stage with no status change. I thoroughly went through guidelines and prepare forums before submitting, not sure what to do next or where my app stands after passing estimated wait times. If anyone from App Review is able to confirm that the submission is properly queued or let me know if there's anything I need to do I would really appreciate it. Thank you!

Hello, I'm evaluating Foundation Models announced at WWDC 2026 and have a question regarding App Store distribution. My understanding is that Foundation Models are only available on supported devices and operating system versions. For apps that rely on Foundation Models as their primary functionality (rather than offering AI as an optional feature), I'm trying to understand the recommended distribution strategy. Currently, iOS provides Required Device Capabilities to prevent users from installing apps that require hardware features such as GPS, ARKit, or NFC. However, I couldn't find an equivalent Required Device Capability for Foundation Models. I also couldn't find a way to limit App Store availability by supported device models. My questions are: What is the recommended way to distribute an app whose primary functionality depends on Foundation Models? Is there currently any supported mechanism to prevent users with unsupported devices from downloading such an app? Is Apple planning to introduce a Required Device Capability (or a similar App Store filtering mechanism) for Foundation Models before public release? Without such a mechanism, users may be able to install the app successfully but then discover that its primary functionality is unavailable on their device. I'd appreciate any guidance on the recommended approach. Thank you.

App: Sprin World, Apple ID 6759182613. Our first three auto-renewable subscriptions (com.sprinworld.app.pass_weekly / pass_monthly / pass_yearly, group 22209642) were rejected July 8 under Guideline 3.1.2(c) for a missing Terms of Use link in the App Description. We fixed the metadata and resubmitted the three products on July 10, and also submitted version 2.5.2, whose review notes ask that the products be reviewed together with the version. An expedited review was granted July 10 at 5:15 PM PT. As of July 11, version 2.5.2, all three subscription products, and the subscription group localization still show Waiting for Review. The subscription UI is visible to live users, who currently cannot purchase. Is there anything else we should do so the subscription product reviews get picked up alongside the version? Thank you.

Hi everyone, I submitted my app's first build for external TestFlight testing and it has been sitting in "Waiting for Review" for more than 48 hours. There are no messages in the App Review section and no rejection, the status is simply "Waiting for Review", so it doesn't look blocked, just not picked up yet. A few questions for those who've been through this: For a FIRST external Beta App Review, how long did yours actually take? Is 48h+ normal these days, or is something wrong? Does the first external review really take much longer than later builds? I've read that once your app clears Beta App Review the first time, subsequent builds are approved almost instantly, can anyone confirm from experience? Has contacting App Review support ever actually sped this up for you, or is it just a matter of waiting it out? Any real-world experiences or rough timelines would help me set expectations. Thanks a lot!

Some users tried to subscribe in my office and they did not able to purchase the subscription for my app "Feedalto" - I realized even the app was approved but the subscription was not. How to solve this problem?

I am stuck in an endless chicken-or-the-egg loop. The last 3 versions of the app have all complied with Guideline 3.1.1. The app shows the products (a yearly and monthly subscription) on the paywall, but the products themselves keep getting rejected citing 3.1.1 saying that the I need to upload a new binary that shows the products on the paywall, and that I need to attach the products to the build - which there is no way to do. When I upload the new binary, the products do not show up on the new app version page to attach them to the build. When I go to submit, the subscription products are not attached to the review panel. So, I submit, the app gets approved, and the subscriptions get rejected. There is no way for me to connect these subscriptions to a build in App Store Connect so it keeps getting rejected. I wrote support and they responded saying they couldn't help and that I should go the forums. While this issue is widespread on the forums, no one has a clear answer as to how to get out of this loop. I have many apps and have never had this issue. Please advise.

Hi, I was creating an iOS app for my country Ethiopia that has in app purchase to unlock app features. The apple policy says for such payment, we must use Apple IAP but not external payment methods such as stripe or local. However, in my country, Ethiopia, Apple IAP is not available. My question is can I use local payment methods or guide users on how to pay using available payment methods in the country where Apple IAP is not available? I need to make sure my app is acceptable during review using local payment method just because Apple IAP is not available in my country. Thank you

I submitted an updated version of my app for review on May 18, 2026, and its status has remained "Waiting for Review" ever since. It has now been more than two weeks without any progress or communication from Apple. To resolve the issue, I have: Submitted multiple support tickets through Apple Developer Support. Received the standard message that I would receive a response within 48 hours. Waited more than 15 days, but have not received any reply to any of my tickets. Attempted to contact Developer Support by phone during U.S. business hours, but after waiting on hold for more than two hours, I was unable to reach anyone. This delay is affecting my ability to release important updates to my users, and I am running out of options. Has anyone experienced a similar situation recently? Is there any other channel or escalation process that I can use to get assistance or have my submission reviewed? Any guidance would be greatly appreciated. Thank you.

I am using CI/CD method to build my apps, i dont have xcode simulator, so I cannot produce 13'' screenshots And I have an ipad that is NOT 13'' what can I do? I am locked out from releasing on ipads?

Apple is committed to keeping the App Store a safe place for users to get apps and a great opportunity for all developers to be successful. A reliable review process is critical to this commitment, which is why App Review works around the clock to review at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Updates with minor changes and bug fix submissions typically move swiftly through review, while other reviews may take longer because they require additional verification. In this post, we'll explain when that can happen and how you can best prepare your submission for a thorough review. Why some reviews require more time While most submissions are reviewed within 48 hours, some apps may require additional time because the review involves extra verification steps, such as: Documentation review, where App Review requests and verifies supporting materials such as authorizations, licenses, or partnership agreements before approving the submission. Complex or novel issues, including apps with regulated content, new platform capabilities, entitlements enabled, or other sensitive features, may require greater scrutiny and consideration. Common examples may include: Medical apps involving health data, diagnostic or treatment features, or other medical claims often require documentation supporting those claims or demonstrating regulatory approval. (Guideline 1.4.1) Cryptocurrency exchange apps must be offered by an approved exchange and secure the necessary licensing to operate on each storefront where the app is available. (Guideline 3.1.5) Apps operating in highly regulated industries, such as banking and financial services, air travel, healthcare, and similar sectors, must be submitted by authorized legal entities with supporting documentation. (Guideline 5.1.1(ix)) Apps with third-party intellectual property require verifiable permission to use another party's content, branding, or other protected material. (Guideline 5.2.1) Gambling, lotteries, and real-money gaming apps must provide the necessary licensing and permissions for each storefront where the app is available. (Guideline 5.3.4) If your app falls into one of these categories, the most effective way to reduce your review time is to attach all requisite documentation we'll need for review in the App Review Information section of App Store Connect. Why this matters: Incomplete submissions require additional back-and-forth before we can complete the review. Including everything upfront is the fastest path to a decision. Best practices to minimize delays 1. Provide complete information on every submission. Give App Review everything needed for a complete review, especially for apps with regulated, specialized, or otherwise complex content. Do: Include demo accounts, authentication codes, and any required setup steps in the App Review Information section. Use the Notes field to explain your app's concept, business model, or authorization to operate in regulated industries. Attach all relevant supporting documentation before submitting the app for review. If you're unsure what information is needed for review, schedule an App Review appointment through Meet with Apple to discuss your app's concept. Don't: Don't resubmit the app for review until all identified issues are resolved. Why this matters: Resubmitting with unresolved issues will result in the same outcome, meaning the submission spends additional time in the queue without a different result. 2. Only provide authentic and verifiable information on your developer account. Authentic account information and high-quality apps build customer trust and keep your submissions moving smoothly through review. Do: Keep your developer name, Support URL, and account information current. Provide authentic, verifiable documentation whenever it's required. Only submit apps that have been thoroughly tested on physical devices and are ready for distribution. Don't: Don't submit documentation you're not authorized to use, or that can't be independently verified. Don't misrepresent your identity or relationship to other brands or services. Don't submit apps that are low-quality, untested, or include incomplete content or features. When fraud or malicious activity is detected To protect the App Store's high standards for privacy, security, and quality, we have zero tolerance for fraudulent or malicious activity. App Review investigates all reported or identified conduct that falls outside the App Review Guidelines and the Developer Code of Conduct, which requires accurate representation and integrity across the App Store experience. Examples include: Misrepresented developer identity or impersonation, such as providing inauthentic documentation or otherwise pretending to be someone you're not (Guidelines 4.1 and 5.6.2). Manipulation of the App Store experience, including gaming charts, search results, reviews or referrals, or attempting to hide features in review (Guidelines 2.3.1(a) and 5.6.3). Submitting low-quality apps, as indicated by excessive customer reports, such as negative customer reviews, and high-volume refund requests (Guidelines 4.3 and 5.6.4). When these signals appear, we investigate thoroughly, and repeated or serious violations can lead to additional rejections, app removals, and account removal from the Apple Developer Program. Support before or during your review If you have a critical timing issue, such as fixing a critical bug or releasing your app to coincide with an event, you can request an expedited review. If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. You can also reply to request a call with an Apple representative to discuss the outcome of the review. If your app has been rejected and you believe it follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Appeals must include specific, detailed explanations for why your app follows each of the guidelines in question.

Hello, my app id 6756081224 Waiting for Review 10 day ago Help me please

I deleted Build 16 from the external Test Flight review approval because I want Build 17 to be used and set up for external review. I successfully removed it and it is not showing up under external testing.. but when I try to add my Build 17, it is greyed out and says that Build 16 is still waiting for review. Can you please fix this as soon as possible so I can begin the review process for my Build 17? Please let me know what information you may need. I'm hoping to get this resolved ASAP.

Hello everyone, I’m wondering if anyone has experienced a similar situation. My app is very simple, with no more than five screens. On my first submission, it remained “In Review” for more than 10 days (not “Waiting for Review”), and during that entire time the App Review team never made a decision—no approval, no rejection, and no request for additional information. After waiting that long, I canceled the submission and submitted the app again. It has now been more than one week, and it is still “Waiting for Review” with no progress. I have contacted Apple Developer Support several times. They have escalated the case, and each time I am told that I should receive an update soon. However, I have now been waiting more than 20 days in total, and I still have no decision or meaningful update. Submission ID: 001dd566-c306-477b-856b-639a0fa7cf1b Has anyone experienced this kind of delay? If so, how was it resolved? Any advice or shared experience would be greatly appreciated.

Hi App Review team, I'm posting here as a last resort after7 weeks with no movement and 4 unanswered support requests. I'm about to lose my launch window next week and I need someone at Apple to look at this. The situation: App: BMH Themes — App ID 6763770421 — Bundle ID com.bringmedinahome.bmhthemes Version 1.0 (Build 24): reviewed and APPROVED, currently "Ready for Distribution". In-app purchases: 904 are APPROVED, but 1,134 have been stuck in "Waiting for Review" for 7 weeks. The 1,134 stuck items are the exact same type as the 904 already approved — so this is clearly not a content issue. None of the 1,134 show any rejection or "Developer Action Needed" message. Nothing is pending on my side. I have submitted 4 support requests over the past weeks. None received a substantive response. Why this is urgent: My company is now legally registered, my VAT number is being issued, my business bank account is active, and my full marketing campaign is finalized for a launch next week. I cannot launch with 1,134 of my products frozen — releasing a half-empty catalog would waste the entire launch. These stuck in-app purchases are the ONLY remaining blocker. My request: Could someone please check whether these 1,134 in-app purchases are correctly queued, confirm whether there is an internal processing issue, and escalate to the App Review / in-app purchase team? The app is already approved — only these items are stuck. Thank you very much for any help.

Hi everyone, I’m an indie developer and recently published our first app on the App Store. It was an exciting milestone, but on April 4, 2025, after the app had been live for about 1–2 weeks and one update had been pushed, we received a notice from Apple stating that our app had been removed from the store and that our developer account is scheduled for termination within a month. Understandably, this was incredibly alarming—but we stayed calm, carefully read through the allegations, and tried to handle the situation with patience and professionalism. The reason given was: App submissions from your account have engaged in concept or feature switch schemes to evade the review process, such as dynamically populating different app content after review, submitting apps with hidden features, repeatedly submitting misleading apps, and/or submitting apps with concrete references to content that you are not authorized to provide or is otherwise not appropriate for the App Store. This was cited as a violation of Section 3.2(f) of the Apple Developer Program License Agreement. We were accused of dynamically changing game content after review, but we do not have the capability to do anything like that. The game has stayed exactly as it was when submitted, and the single update we pushed included only the changes listed in the “What’s New” section. They also mentioned hidden features. While we don’t hide anything, our game does include progression-based unlocks (such as new upgrade cards or mechanics unlocked as you play). We believe this is standard for many games, and we’ve explained this in our appeal. We also addressed another possible issue—some light pop culture jokes in push notifications—which we are more than happy to remove immediately if they were deemed inappropriate. We’re not here to argue or avoid accountability. If we’ve made any mistakes, we’re more than willing to correct them. But terminating the entire account for a first-time submission, without any discussion or specific feedback, feels incredibly harsh—especially for a small team trying to break into the industry. We submitted an appeal to the App Review Board over a week ago but have not received any response or update since then. So I’m posting here in the hopes of catching someone’s attention—whether that’s Apple or anyone in the community who’s been through something similar and can advise. I know the $99 annual fee might not be a huge deal for many developers, but for someone just starting out, it represents more than money—it’s a foot in the door. I’m not looking for sympathy, just a chance to make things right, follow the rules properly, and keep building on the platform I admire. Thank you for reading, and I truly hope someone can help guide us on the next steps. Best, Veekshith Kolanupaka

Hello, I'm looking for advice from developers who have successfully published internet radio applications on the App Store. My app has been rejected multiple times under Guideline 5.2.3 with the following message: "The app provides potentially unauthorized access to third-party audio or video streaming, catalogs, and discovery services." Apple asks me to provide: "documentary evidence evidencing that you have all necessary rights or permissions to the third-party audio or video streaming, catalogs, and discovery services in the app." However, I'm not sure what documentation App Review actually expects. My application works as follows: • It does NOT host, proxy, cache, retransmit, record, convert, or modify any audio streams. • Playback uses Apple's AVPlayer. • Audio is streamed directly from the original broadcaster to the user's device. • The application only retrieves publicly available station metadata and stream URLs from the Radio Browser API. • The app no longer contains any built-in curated station list. • Music identification uses Apple ShazamKit together with metadata lookup (MusicBrainz, Last.fm and Apple iTunes Search API). These services are used only for metadata and artwork, not for streaming audio. I have already contacted the Radio Browser maintainers asking whether they can provide written permission or an official statement, but I have not yet received a reply. My questions are: Has anyone successfully published an App Store internet radio application that uses the Radio Browser API (or another public radio directory)? What documentary evidence satisfied App Review? Does Apple expect permission from the Radio Browser project, or from every individual broadcaster whose publicly available stream is listed in the directory? If your app was approved, what documentation did you provide? Any experience or guidance would be greatly appreciated. Thank you. Has anyone received a successful approval for an internet radio app under Guideline 5.2.3 in 2025 or 2026?

Hello Apple Developer Community / App Review Team, I am writing to ask for guidance regarding an App Review process that appears to be stalled, and also to raise a broader concern about review transparency and communication. I submitted my app for review on July 1, 2026, at around 1:23 PM. As of July 8, 2026, at 2:37 PM, it has been waiting for more than 7 days. During this period, my app appears to have been accessed by three different reviewers. Based on the activity I can see, they entered the app and reviewed it, but the submission status in App Store Connect never formally moved to “In Review.” This creates a difficult situation for developers. It is unclear whether the app is actively being reviewed, stuck in an internal step, waiting for further action, or simply forgotten in the queue. I have been developing for iOS for approximately 7 years, and I have not experienced a review process where it was this difficult to find a clear point of contact or receive a meaningful status update. I have contacted App Store Connect Help multiple times — approximately 3 or 4 times — but I have not received an email response. I have also tried reaching out through other public and professional channels, including LinkedIn and X, not to create pressure, but because I could not find a reliable way to understand what is happening with the submission. My concern is not only about one app or one review delay. I believe this is also an operational issue that affects the broader Apple developer ecosystem. A more transparent, accessible, and trackable App Review process would benefit both developers and Apple users. When developers have clearer visibility into review timelines and status transitions, they can plan releases better, respond to users faster, fix issues more responsibly, and ship higher-quality products. This directly improves the experience of people using Apple products every day. I would appreciate clarification on the following: Is it expected that reviewers may access an app before the submission status changes to “In Review”? What does it mean when reviewer activity is visible, but App Store Connect does not reflect an active review state? Is there currently a backlog or operational delay affecting App Review timelines? What is the recommended path for developers when a submission appears to be stalled for more than 7 days with no response from App Store Connect Help? Are there any planned improvements to make App Review status transitions more transparent, predictable, and easier to follow? Apple holds developers to high standards, which is understandable and valuable for the platform. At the same time, developers need a process that is easier to track, easier to understand, and more responsive when something appears to be stuck. I would appreciate any guidance from Apple or the developer community on how to proceed with this specific review, and I hope Apple continues improving communication and visibility around App Review operations. Respectfully.

Hello Apple Team, Why Is Apple Forcing Us to Use Its In-App Payment System? I am writing this as the CTO & Co-Founder of BS Fintech Pvt. Ltd., India, who is deeply disappointed with our experience over the past six months. Our fintech app, ScoreUp, has been live on the Google Play Store, where it has been serving customers successfully with 99.99% uptime and excellent user feedback. We have invested years of effort in building a reliable product that fully complies with Indian regulations. However, despite multiple submission attempts over the last six months, Apple App Store approval has not moved forward because we are not using Apple's In-App Purchase (IAP) system for subscriptions. This raises an important question: Why are developers forced to use Apple's payment system instead of being allowed to use compliant third-party payment providers? In India, we already work with trusted payment gateways that support UPI and comply with all RBI and NPCI guidelines. These providers process a ₹99 subscription for approximately ₹0.30 per transaction. In comparison, Apple's commission of up to 30% on the same subscription creates a significant financial burden, particularly for startups building affordable subscription-based products. Apple cannot force us to use its payment gateway, which is significantly more expensive than other compliant payment solutions. We strictly adhere to all applicable regulations and compliance requirements prescribed by the Government of India, RBI, and NPCI. Our intention is not to bypass any regulations but to use a fully compliant and cost-effective payment solution that best serves the Indian market. We simply want the freedom to choose a payment solution that is: Fully compliant with Indian laws and regulatory requirements. Cost-effective for our business and our customers. Better suited to the Indian payments ecosystem. Startups invest enormous time, capital, and effort into building innovative products. Restricting app distribution because a developer chooses a compliant third-party payment provider creates a significant barrier for businesses trying to innovate and compete. I would sincerely appreciate clarification from Apple on the following: Why can't our app be approved while using a fully compliant third-party payment gateway? How does this requirement support fair competition and developer choice, particularly in markets like India with a mature, regulated digital payments ecosystem? We hope Apple will continue supporting developers by providing greater flexibility and recognizing regional payment infrastructures that are already secure, regulated, and widely adopted. We look forward to a constructive dialogue and a fair resolution. I request a prompt response and a clear resolution to this matter. You may contact me. If this issue cannot be resolved satisfactorily, I will have to explore all available legal remedies to protect our business interests, including seeking appropriate compensation for the business losses we believe have resulted from this policy and its impact on our app's launch in India.